Extensible information distribution mechanism for session management

ABSTRACT

A technique for managing conference state. Endpoints of the conference are application processes ( 1803 ) running on computer systems that are connected by a WAN ( 1811 ). Each of the application processes ( 1803 ) maintains endpoint state for the conference. A session manager process ( 1812 ) in each of the computer systems maintains session manager state for each of the conferences that has an endpoint on the computer system. The session manager conference state includes a copy of the endpoint state for each of the conferences and the session manager ( 21 ) uses a locking mechanism to that the copies of the session manager conference state in all of the session managers ( 21 ) are identical. When an endpoint changes its endpoint state, it informs the session manager ( 21 ), the session manager ( 21 ) incorporates the change into its session manager conference state, and when the locking mechanism permits, exports the change to the session managers ( 21 ) for all the other endpoints. When the session manager ( 21 ) receives a change, it incorporates the change into its session manager conference state.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims priority from U.S. provisional patentapplication 60/191,707, Michael B. Haley, et al., Extensible informationdistribution mechanism for session management, filed Mar. 23, 2000.

BACKGROUND—FIELD OF INVENTION

This invention relates to the dissemination of information in networkedcomputer software, specifically for the purposes of distributed sessionmanagement, that is, the management of participating users and softwaremodules in a distributed computing environment.

BACKGROUND—DESCRIPTION OF PRIOR ART

It is common modern software practice to develop software applicationswhich are distributed. Examples of such applications range from videoconferencing systems to virtual environments and 3D games. Typically,when a distributed software application is running, it manifests itselfas a collection of software applications, with each application runningon a workstation connected to the public Internet. The public Internetmay be considered to operate as a wide area network (WAN). In ourdiscussion here the term “end-point” will be used to refer to aparticular application executing on a single workstation.

These distributed software applications group each end-point into aconference of end-points. Here the term “conference” refers to thelogical grouping of the end-points. The establishing of this conferenceof end-points is a complex process due to the simplicity of theunderlying WAN protocols. Furthermore, once end-points are grouped intoa conference it is necessary to communicate state and configuration dataof the end-point applications between each participant. Once again thisis a complex task to perform reliably and efficiently.

In these applications a “session-manager” software component is usuallyemployed. This software component is responsible for identifying andmonitoring the participants in the conference and can also be maderesponsible for communicating the state and configuration informationbetween end-points. Traditionally session-manager implementations sufferfrom many flaws that we have overcome in our invention.

The session-manager approach was used in the MBONE project in early 1990as presented by Hans Ericksson in “MBone—The Multi-cast Backbone, INET1993. In the MBONE project a “session directory” application wasprovided which managed the list of people with whom one mightcommunicate using the IP multicast standard. Numerous protocols such asthe session announcement protocol (SAP) and the session initiationprotocol (SIP) were employed in this implementation. This manifestationof session management was very simple and included only the most basicinformation about the user such as a name and a location. It did notinclude any information regarding the user's application or anyinformation about other forms of communication open between users. Alsoit did not operate as a readily usable process for applications to usefor session management.

Most “session-management” applications generally execute as externalprocesses on all computer workstations that are participants incollaborative network sessions. The main application software willcommunicate with the “session-manager” to advertise its presence to theother participants of a conference or to announce the existence of a newconference. (In our terminology here a “conference” refers to a logicalgrouping of end-point applications on the same WAN). When an end-pointapplication terminates or disconnects from the conference the“session-manager” is also responsible for announcing this fact to theother participants.

In most applications the use of the “session-manager” to locate otherparticipants and to announce one's presence is only a first step.Normally this will be the prerequisite for initiating some other form ofcommunication between the known participants. An example of this wouldbe a video conferencing application where once the participants in thevideoconference are known, a digital video signal is generated fromnumerous end-points and is communicated to all other end-points. Inorder to generalize and automate the initiation of this other form ofcommunication it is necessary to communicate its parameters and itsnature between the participants. This type of “extended” behavior is notprovided by most session manager implementations and this is the focalpoint in the design of our system.

Most early systems that required session management used a client-serverapproach, as maintaining data at a single source obviates the need forcomplex arbitration or locking techniques. However these client-serverbased systems suffer from numerous disadvantages such as:

(a) Low error tolerance—if the server fails then everything fails.

(b) Lack of scalability—all participants need to communicate to the samenetwork end-point. When the number of participants exceeds a thresholdthe communication becomes prohibitively slow and eventually impossible.

The reliability and scalability problems of the centralized sessionmanagers can be overcome using distributed session managers. Examples ofthis approach are:

U.S. Pat. No. 5,748,618 to Rothrock (1998) discloses a mechanism forarbitration in a distributed data conferencing system for accessingshared data stored using a hierarchical representation. The patent isconcerned with sharing visual data in small-scale (not suffering fromthe disadvantages mentioned above) collaborative environments and doesnot consider scalability issues of moving to larger systems as well asgeneralized data distribution between conference participants.

Similarly U.S. Pat. No. 5,634,010 to Ciscon (1997) addresses solely thecommunication of data between external processes. No consideration isgiven to the greater problem of identifying external processes andlogically grouping them into conferences.

Some software systems (for example the Nexus system for developingapplications, described in I. Foster, C. Kesselman, S. Tuecke, “TheNexus Approach to Integrating Multithreading and Communication”, Journalof Parallel and Distributed Computing, 37:70-82, 1996), providesession-management functionality.

None of the prior-art session managers in both completely distributedand completely extensible. Session managers with these characteristicsare required to support modern collaborative network software. Problemsin the design of completely distributed session managers include thedivision of session management tasks between the end point and thesession manager, the amount of state maintained in each session manager,and avoiding deadlock and race conditions in making changes in thesession managers. Problems in the design of easily extensible sessionmanagers include making it possible to add new kinds of applications andconferences or use the session manager on different platforms withouthaving to redesign the session manager. It is an object of the inventiondisclosed herein to overcome these problems and provide a completelydistributed, completely scalable, and completely extensible sessionmanagement system.

SUMMARY

The session manager of the invention provides a completely distributedsession management system by maintaining session manager conferencestate that ensures that each end point in a conference has a currentcopy of the endpoint conference state for the conference. A givensession manager provides any changes made by its endpoint in theendpoint conference state to the session managers for the other endpointand provides any changes in the endpoint conference state that itreceives from other session managers to its endpoint. A distributedlocking mechanism in the session manager conference state ensures thatthe given session manager sends changes to the other session managersonly when all of the other session managers are ready to receive them.Complete scalability is achieved because a given session managercontains session manager conference state only for those conferencesthat have endpoints on the computer system in which the session manageris executing.

In another aspect of the invention, the session manager maintains acomplete copy of the endpoint conference state in the session managerconference state. Where the endpoint conference state is hierarchical,the copy in the session manager conference state uses a representationof the hierarchy which remains valid when part or all of the copy of theendpoint conference state is provided to another session manager.

When an endpoint wishes to join a conference, all that is required isthat its session manager obtain a copy of the session manager conferencestate from another session manager and provide the endpoint conferencestate in the copy to its endpoint. When an endpoint establishes aconference, the endpoint makes the endpoint conference state for theconference, the session manager makes session manager conference statefor the conference including the endpoint conference state, and whenanother endpoint joins the conference, the session manager provides itssession manger conference state to that endpoint's session manager.

The session manager of the invention is completely extensible becausethe operations it performs are restricted to incorporating changes inthe endpoint's endpoint conference state into the session managerconference state for the conference, providing the changes in thesession manager conference state to the session managers of theconference's other endpoints, receiving changes from the other sessionmanagers, incorporating them into the session manger conference state,providing changes in the endpoint conference state portion of thesession manager conference state to the endpoint for incorporation intothe endpoint conference state, and using the locking mechanism to ensurethat each session manager's copy of the session manager conference stateis the same as that of all the others. The session manager thus needhave no knowledge whatever of the details of the endpoint's endpointconference state.

The session manager is further independent of changes in endpoints,conferences, and platforms because it employs a representation for thesession manager conference state which can represent any form ofendpoint conference state. A translator running in the endpointtranslates endpoint conference state into the proper form for thesession manager conference state and vice-versa. In a preferredembodiment, the representation is XML, with translation to and from XMLfor a particular combination of conference, endpoint, and platform beingdefined by a DTD for the combination that is accessible to thetranslator.

Still further objects and advantages will become apparent from aconsideration of the ensuing description and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and benefits of the present invention will become clearerand more apparent following a detailed description of the preferredembodiment in conjunction with the following drawings:

FIG. 1 shows a network level view of a workstation with a sessionmanager component connected to a WAN.

FIG. 2 shows the same network level of a session manager componentconnecting to a WAN, but this diagram depicts two workstationsconnecting, and potentially communicating.

FIG. 3 shows numerous workstations connected to a WAN with their sessionmanagers all potentially communicating.

FIG. 4 depicts the configuration of installed software and networkinterfaces for a single workstation running a single applicationinstance.

FIG. 5 depicts the software and network interactions for a singleworkstation running numerous applications simultaneously.

FIG. 6 is a diagram of logical software processes executing on a typicalworkstation and the separation of the software components internal toeach process.

FIG. 7 contains a diagram of a typical hierarchy of objects maintainedat both the application level and at the session manager level.

FIG. 8 depicts the same hierarchy of objects at both session manager andapplication levels but also depicts the interactions between equivalentobjects.

FIG. 9 is a diagram of hierarchical object communication over a WAN fromthe viewpoint of one specific session manager.

FIG. 10 shows a particular hierarchy of objects within a sessionmanager, with some objects co-owned by conferences.

FIG. 11 shows the necessary lock groups that exist in order tofacilitate ordered object access in the session manager.

FIG. 12 depicts numerous workstations running session managers over aWAN and sharing data through the use of two locking tokens.

FIG. 13 is a high level flow chart of a typical network-based softwareapplication that is using our session manager.

FIG. 14 is a flow chart showing the process by which our session mangerlocates conferences.

FIG. 15 shows a flow chart of the techniques used in our session managerfor creating and joining a known conference.

FIG. 16 contains a flow chart showing the process by whichconference-specific objects are modified or created.

FIG. 17 depicts the flow chart for the session manager's response toobject updates from the network.

FIG. 18 is a detailed overview of a session manager and a set ofapplication processes in a workstation.

FIG. 19 is a detailed view of an info object.

DESCRIPTION OF THE PREFERRED EMBODIMENT

System Hardware

FIGS. 1 through 3 depict the reference system hardware necessary forexecuting our invention, consisting of one or more workstationsconnected to a WAN. The workstations referred to contain amicroprocessor and primary memory for storing and executing thesoftware, as well as secondary storage for static storage of thesoftware and data files required. Each workstation is in turn connectedto a WAN using one of a number of available network interfaces. Themedium of communication may be any medium that supports logicalidentification of endpoints, automatic routing between endpoints,reliable point-to-point communications, as well as non-reliablemany-to-many communications. In FIG. 1 only a single workstation isconnected to the WAN (depicted by a cloud). The WAN consists of apotentially infinite collection of workstations some of which areend-points and others are routers to different sub-networks. Thecommunication transports used between routers and workstations may rangefrom high-speed LANs (local area networks typically employing anEthernet) to POTS (plain old telephone systems) connections. Thereforethe data transfer between any pair of workstations on the WAN may occurthrough numerous different media each with its own characteristictransfer rate and data loss rate. In FIG. 2, workstation 1 andworkstation 2 may communicate with each other but a network route mustfirst be established between the two workstations. Establishing theroute involves determining the location, identification andidentification of the network end-points, followed by the transfer ofdata. This functionality is intrinsic to most WAN protocols and fallsoutside the scope of our invention. In FIG. 3, numerous workstations areintercommunicating on a many-to-many basis across the same WAN. Onceagain the data is being “routed” between the workstations over amulticasting network of interconnections (The term “multicast” refers tothe ability to transmit data onto the WAN and have it received by anymultitude of workstations that are listening for the data.) This type oftransfer is often referred to as “unreliable multicast transfer” and isgenerally an unreliable mechanism for communicating data, i.e. datapackets can be lost or may change packet ordering.

It is however, possible to implement another level of protocol on top ofan existing unreliable multicast implementation to achieve a reliable(no data is lost or mis-ordered during transmission) multicast thatguarantees no data loss and maintains packet ordering. It is thismechanism that our invention uses for communicating among the sessionmanager components on distributed workstations. An example of such ahigher-level protocol is the well-known TCP protocol belonging to theInternet protocol suite.

Software Environment

FIG. 4 depicts a common execution environment for our invention.Application 10 interacts with the workstation user 9, and whenever anyconference-specific data communication (data which is logicallyconnected to a particular conference) needs to occur, the applicationcommunicates with session manager component 13 that is executing on thesame workstation. The communication is performed using a well-definedinterface between session manager 13 and application 10. The sessionmanagement component 13 then communicates changes made by application 10in the conference-specific data to other remotely executing sessionmanagement components via the network as depicted in FIG. 2 and FIG. 3.Similarly, any changes in conference-specific data for application 10that arrive from remote session management components via the network isreceived by session manager 13 and possibly transferred to application10.

FIG. 5 shows the same environment but with numerous applications:application 10, application 11, and application 12; all executing on thesame workstation. Once again, only a single session management componentis required, and all conference specific data communication is carriedout by first communicating with session manager 13, and then sessionmanager 13 in turn communicates with the remote session managers overthe WAN as depicted in FIG. 2 and FIG. 3. Information arriving from thenetwork at session manager 13 is then dispatched according to relevanceto one or more of the applications: application 10, application 11, andapplication 12.

The executing processes may therefore be divided into two categories:application or session manager. For the purposes of further discussion,however we will refine this categorization a little further in FIG. 6.Here process 20 is an application process, and process 21 is a sessionmanager process. As explained above they interact through a definedinterface, which allows data objects to pass from the application to thesession manager and vice-versa. The application process may be dividedinto two sections: an application code section 20A, which consists ofapplication-specific source code; and a framework-specific section 20B,which consists of network source code for communicating with the sessionmanager. The application code 20A communicates with the framework code20B and framework code 20B in turn communicates with the workstation'ssession management component 21. The use of framework code 20B hides thedetails of communicating with the session manager from application code20A.

Similarly the session management component 21 may also be divided intothree parts: client interface 21A responsible for communicating with theapplications on the same workstation; repository 21B for storinghierarchies of objects for the conferences in which the applications onthe workstation are participating; and network interface 21C responsiblefor communicating with remote session management components over thenetwork. It should be pointed out here that an important aspect of thescalability of the distributed session management system disclosedherein is that each session manager contains only the state necessaryfor the conferences in which applications on that session manager's workstation are currently participating.

Conferences and Session Objects

In our discussion, “conference” refers to a logical grouping ofend-points running on a possibly disparate collection of workstations asdepicted in FIG. 3. An application process that currently belongs to aconference maintains a hierarchy of objects that contain theconference's state, as depicted in process 20 in FIG. 7. Here twoconferences are established, conference 30 an conference 30′. Thenbelonging to these conferences is object 30A, object 30B, and object 30Crespectively where object 30B belongs to both conferences. Object 30Dbelongs to object 30A. Object 30E belongs to object 30B, and object 30Fbelongs in turn to object 30E. Therefore this hierarchy represents adirected acyclic graph with many root needs, each one a conference.

In any software application that creates and manages the said objects,the complexity of the objects may be high and the storage scheme may beoperating system-specific or hardware-specific. To alleviate this and toachieve platform independent, the session manager component builds anintermediate representation of the application objects called “info”objects in repository 21B. The intermediate representation is used inall of the session manager distributed session manager components and isalso the form in which conference state is sent from one session managerto another across the network. Included among the info objects is aconference object that describes the conference participants and thesecurity required to join the conference. Associated with the conferenceobject are information objects that contain exact reproductions of theinformation in the objects that the application process uses torepresent the conference state. The session manager is thus able tomaintain in its repository 21B a hierarchy of info objects which mirrorsthe hierarchy of objects maintained by the application process. This isshown in FIG. 7 where application process 20 has created a hierarchy ofobjects and the session manager 21 maintains a matching hierarchy ofinformation objects. The conference objects are at 31 and 31′. In apreferred embodiment, objects corresponding to the conference objectsare included in the hierarchy maintained by the application process; inother embodiments, the conference objects may be invisible to theapplication processes.

As the application makes changes to its objects, these changes arereflected to the session manager, which in turn changes thecorresponding info objects and sends copies of the changed info objectsvia the network to the session managers for other conference end points.If the session manager receives a changed object belonging to theconference state from another session manager, then the session managerchanges the corresponding info object in its repository and reflects thechange to the application process. The manner in which changes made inthe application process's hierarchy of objects is reflected in thesession manager's info objects and vice-versa is expressed in FIG. 8.

The manner in which the session manager outputs changed info objects tothe network and receives them from the network is shown in FIG. 9.There, if info object 31C were to change (as a result of an objectchange at the application level) then all session managers on thenetwork containing conference 31′ would be notified of the nature of thechange. If info object 31F were to change then all session managerscontaining either conference 31 or conference 31′ will be notified. Atany time a session manager may also receive a description of a changedinfo object from the network (depicted as an arrow towards object 31A inFIG. 9).

Our discussion here centers on the changing of existing applicationobjects or info objects, but similarly when objects are created anddestroyed at the application level these facts are forwarded to thesession manager, which modifies its own information objects and thencommunicates the creation or destruction to other session managerscarrying the relevant conferences. The exact method by which changes arecommunicated across the network may be any of a number of prior arttechniques for low-level network communication of data to multipleend-points.

Representing the object hierarchy

As presented in FIG. 7, the application process 20 and the sessionmanager 21 maintain equivalent object hierarchies. In both hierarchiesthe relationships between the objects are represented by information ineach the object that identifies the object's parent(s) or children. In apreferred embodiment, the application process assigns each object in theapplication process's hierarchy a unique uniform resource locator (URL);where an object is a parent or child of a given object, the given objectuses the other object's URL to identify it as a parent or child. The URLthat the application project assigns to each object is based on theidentity of the workstation, the conference in which the object exists,and the nature of the object. These same URLs are then used in the sameway in the corresponding info objects in the repository. Moreover, theURL persists during the transmission over the network, in the repositoryof the receiving session manager, and in the object hierarchy maintainedby the end point at the work station on which the receiving sessionmanager is executing. Consequently, a given info object's URL is used byeach session manager to refer to the session manager's copy of the infoobject and to the corresponding object maintained by theapplication-level process that is running in the session manager'sworkstation. The URLs are also used for communicating object deletion orcreation from the application level to the session manager level andvice versa.

Representing information in the info objects

If the session management system is to be usable with applicationrunning on many different kinds of workstations, the info objects mustbe represented in a platform-independent and operatingsystem-independent way. Moreover, the representation must be such thatthe session manager can perform its functions without any knowledge ofthe contents of the application-level object represented by the infoobject. Finally, the representation must be such that it can be easilyextended to new kinds of platforms and new applications.

All of these issues are dealt with in the preferred embodiment byencoding the contents of the info objects in the well-known XML(Extensible Markup Language). For details, seehttp://www.w3.org/TR/REC-xml.

Whenever an object is communicated from the application process to thesession manager, the object is encoded in XML; whenever an object iscommunicated from the session manger to the application process, theobject is decoded from XML. When the session manager sends an object toanother session manager via the network, the object remains encoded inXML. The encoding and decoding of the application object's contents aredone by framework code 20B executing in the application process. As isstandard practice with XML, the manner in which the XML is encoded ordecoded is determined by a document type definition (DTD) particular tothe application. The DTD may be part of the application, or theapplication may simply have the URL of a DTD.

FIG. 19 shows details of an info object 1901. The object has two parts:session manager information 1903, which is the information the sessionmanager needs to manipulate the object, and application information1905, which is the contents of the object as created and used by theapplication except for the URLs for the object, its parents, and itschildren, which are in the session manager information. Everything inthe info object is encoded by XML. The contents of applicationinformation 1905 are encoded and decoded using the DTD specific to theapplication; the contents of session manager information 1903 areencoded and decoded using a DTD that is common to all of the sessionmanagers. As is apparent from this discussion, framework code 20 bencodes or decodes application information 1905, while the sessionmanager encodes or decodes session manager information 1903.

Session manager information 1903 contains the URL 1907 that identifiesboth the given information object and the corresponding object in theapplication process, a list 1909 of URLs 1911 of objects that areparents of the given information object and the correspondingapplication process objects, and a list 1913 of URLs 1915 of objectsthat are children of the given information objects and the correspondingapplication process objects. These URLs are all received from theapplication process that first makes the corresponding applicationprocess objects. Session manager information 1903 additionally includesa list 1917 of URLs 1919 of lock objects, information objects that areused to control access by the session manager to other info objects.Locks and access are managed completely by the session managers. Thelocks are invisible to the application process and the lock objects arenot part of the application process objects. Locks will be discussed inmore detail in the following.

When the info object is a conference object, it is at the top of thehierarchy and has no URLs in parent list 1909. Application information1905 in the conference object contains information about the conferencesuch as the network addresses of the session managers for the otherendpoints and the security constraints that have to be satisfied byendpoints that are joining the conference.

Locking and Tokens

Another problem is distributed session management in the race anddeadlock conditions that can result where many end point cansimultaneously access an information object. The problem is resolved inthe preferred embodiment by means of distributed locks. A lock is simplya mechanism for ensuring that only one end point at a time can changethe information objects for the conference in the session managers andthat the information objects will be changed by all the session managersbefore the next change is made.

Locking is controlled by a token that circulates among the sessionmanagers; when a given session manager has the token for a lock andwishes to change an information object that is associated with the lockin response to a change made in the local endpoint, the given sessionmanager sends a message to each of the other session managers in theconference indicating that the session manager wishes to change aninformation object associated with the lock. The other session managersthen lock their locks, i.e., they will not make changes requested bytheir end point on information objects associated with the lock, andinform the given session manager that they have done so. When the givensession manager has responses from all of the other session managers,the given session manager makes the changes to its own repository,releases the token, and broadcasts the changes to the other sessionmanagers. An object may be associated with more than one lock, and whenthat is the case, the object may be modified only when the sessionmanager has proceeded as described above forth both locks.

Locks are implemented in the session manager by lock objects. Theseobjects are part of the info objects for the conference, but not part ofthe application objects. FIG. 10 depicts two conference info objects:info object 41 and info object 41′, with two locks objects: object 50and object 50′, belonging respectively to the conferences (in additionto the usual copies of application objects). These locks may then beused to lock any info object that belongs to the state of the conferencerepresented by the conference object. For objects that belong to bothconferences it is therefore necessary to unlock both locks to access theobjects shared by the two conferences. FIG. 11 shows a diagram of thearea of influences of the two locks. Here lock 50 is used to lockanything in locking domain 60, and lock 50′ is used to lock anything inlocking domain 60′. However object 41B, object 41E, and object 41F canonly be locked through use of both lock 50 and lock 50′.

The tokens that unlock the locks are implemented using a prior arttoken-passing scheme. As depicted in FIG. 12, a token is associated witheach conference and constantly circulates among all session managersthat contain info objects for the conference. A session manager thatdoes not need to alter any objects belonging to the conference willimmediately pass the token on; otherwise, the session manager willretain the token until it has received permission from the other sessionmanagers to alter the objects, and done the alterations in its ownrepository. At that point, the session manager releases the token andsends the altered objects to the other session managers. A fulldiscussion of token passing-techniques is out of the scope of thisinvention disclosure, as it is prior art and many references areavailable on techniques of token implementations. Issues such as lockcontention can be resolved by adding both locks and tokens. This couldoccur down to a lock-per-object level in a particular conferencehierarchy.

Therefore, as shown in FIG. 12, should workstation 4 (with sessionmanager 4A) desire to access an object in conference 41′, it waits untiltoken 50′ reaches workstation 4. In the diagram session manager 1A andsession manager 1C are holding token 50 and token 50′ respectivelyallowing them to access objects in conference 41 or conference 41′respectively.

Prior art literature on token-passing mechanisms deals with the issuesof fault tolerance and performance. Our token passing scheme isstructured on top of the same reliable multicast communication mechanismused to distribute info objects by the session managers.

Detailed overview of a session management system in a single workstation

FIG. 18 is a detailed overview of a session management system 1801 in asingle workstation. System 1801 has two main components: a set ofapplication processes 1803(a . . n) which are end points in conferencesand a session manager process 1812 that maintains the distributedprocess state for each of the application. One of the applicationprocesses, application process 1803(i), is shown in detail. Applicationprocess 1803(i) is executing application code 20A, which may interactwith a user, as indicated by arrow 1807. Process memory 1805 includesapplication objects 30 for the conference; the application objects havethe form required for the application and the platform upon which theapplication process is executed. The interface between applicationprocess 1803(i) and session manager 1812 is framework code 20B, whichexecutes in application process 1803(i). Framework code 20B translatesbetween the XML representation of application objects 30 used in theprocess manager and the application-specific representation used inapplication process 1803(i). Translation to and from the XMLrepresentation is controlled by application document type definition1809, which may be located anywhere where it is accessible toapplication process 1803(i).

Session manager process 1812 executes client interface code 21A andnetwork interface code 21C as previously discussed; repository 21Bcontains information objects 31 for each of the application process 1803in the workstation that is currently an end point in a conference. Theinformation objects contain XML representations of session managerinformation 1903 and application information 1905 and may also includelock objects. Other information in session manager process 1812's memoryincludes the following:

Information object location table 1817 relates information object URLsto the locations of the information objects in repository 21B. Sessionmanager process 1812 uses table 1817 to find the object in repository21B that needs to be replaced when it receives a new version of theobject from an application process or from the network.

Application process location table 1819 relates object URLs to processIDs for application processes, so that the session manager can determinewhich application process an object that has newly arrived from thenetwork should be passed to.

Lock queues 1816 are queues for objects that have been modified in theapplication processes 1803, have been received from applicationprocesses 1803, and now need to replace their corresponding info objectsand be placed on the network, but are subject to a lock object and mustawait arrival of one or more tokens in session manager process 1812before the corresponding info objects can be replaced and the replacinginfo objects placed on the network. There is one lock queue for eachcombination of locks to which info objects in repository 21B aresubject.

SM DTD 1821 is the DTD that the session manager processes use totranslate session manager information 1903 to and from XML.

Case Study

A typical application scenario is presented here in order to demonstratethe functionality described in the previous sections. A simple networkapplication, which creates or joins a conference and establishes anumber of conference specific objects (i.e. objects which are sharedbetween conference participants), is presented. The processes by whichthis happens and by which the conference specific objects are modifiedand updated across the network are demonstrated.

Overview

In FIG. 13 the flow chart for the application level software of thistypical software application is presented. As with most conference basedapplications the application starts out by presenting the user with alist of active conferences to choose from or attempts to join apredefined default conference. So the application begins (step 100) byrequesting the session manager to locate a specific conference by name(for example, by URL). If (step 101) the conference does not exist thena request is made to the session manager to create the conference (step102). If the conference exists and has been joined or, alternatively, anew conference has been created and joined, the application then fallsinto a state where it creates, destroys, and modifies objects specificto this conference (step 103). This is the normal running mode of theapplication. In this state, the application process will create orchange objects in application objects 30 for the conference (step 104).When this happens the software framework will create an info object inthe conference's info objects 31 corresponding to the changedapplication object (step 105). This info object is then supplied to thesession manager (step 106), which incorporates the supplied info objectto the conference's info objects 31, either by replacing the existinginfo object or adding the supplied info object. Thereupon, the sessionmanager sends the supplied info object to the session managers for theother conference endpoints.

Also during the execution of the application, changes to an objectbelonging to a conference may be caused by another end-point. In thiscase the session manager for the other end point send a correspondinginfo object to the session manager 21 for this endpoint. Session manager21 incorporates the corresponding info object into its info objects 31for the conference and notifies the application (step 109, whichresponds by decoding the corresponding info object (step 108) and thenincorporating the changes expressed in the info object into thecorresponding application's conference-specific objects 30. Furtherdiscussion will now focus on the interval behavior of the sessionmanager in the above situations.

Locating a conference

The flow chart in FIG. 14 expands on the process of locating aconference. When the application process 1803 requests the sessionmanager to locate a conference, the application process specifies adestination workstation which might contain knowledge of the conference(step 200 and step 201). Session manager 21 uses the address to contactthe remote session manager running on the destination workstation (step202) and to query the conference's existence. If (step 203) theconference does not exist, then the remote session manager reports thefailure to the local session manager, which reports it back to theapplication (step 204). However, if the conference does exist, theremote session manager sends a copy of its info objects 31 back to therequesting session manager (step 205). The local session manager addsthe copy to its repository 21B (step 206) and sends the conference'sidentifier on to the application (step 207).

Creating or joining a conference

FIG. 15 explains the process by which conferences are then created orjoined within the session manager. Beginning with conference creation,should the application decide to create a conference (step 300),framework 20B creates a conference object for the conference (301)together with info objects corresponding to any other objects in theapplication's conference state. Since this is a conference object, theobject's logical parent object is set to be NULL or nothing (step 302).The conference info object is then communicated to the session manager(step 303). The session manager checks the object for uniqueness (step304) and if it is not unique, the session manager reports a failure tocreate a conference to the application process (step 305). However ifthe info object is unique, the session manager adds it and the infoobjects corresponding to the other objects in the application'sconference state to repository 21B (step 306).

Continuing with joining a conference, should the application have ratherdecided to join a conference (step 307), then framework 20B creates asession info object (step 308). This info object uniquely identifiesthis application instance (end-point) within the specified conference.Framework 20B further sets the parent of the session info object to bethe conference object for the conference that the application desires tojoin (step 309). The new session object is then communicated to thesession manager (step 310), which once again checks the info object'suniqueness (step 304) and adds the info object to the repository ifsuccessful (step 306). Whenever any info object is added to therepository it is then checked to see if it ultimately has a parent thatis a conference object (step 311). If it does, then that info object iscommunicated to the other session managers (step 313) before returning asuccessful operation (step 312) to the calling application.

Details of adding an info object to a repository in response to amodification by the application process

A more in-depth analysis of the addition of info objects to therepository is now presented in FIG. 16. The application generally beginsby creating or modifying an object in its application objects 30 (step400). The framework then generates a new info object to describe thischanged or new application level object (step 401). This info object iscommunicated to the session manager (step 402), which proceeds bylocating the conference info object for this info object's conference(step 403). Once the conference info object is located, the sessionmanager determined whether it has a token for the conference's lock(step 404). If (step 405) a token is not found then the session managerwaits for ownership of this token (step 406). If (step 407) the sessionmanager fails to get the token then an error is reported back to theapplication (step 408). However if the token obtained, then the new infoobject is stored in the repository (step 409). If there is no lock, thenthe session manager simply adds the object to the repository (step 409).

Once the info object is added to the repository, the session managercommunicates it communicated to all other session managers in the sameparent conference (step 410) and then releases the token (if one wasused) (step 411). The session manager then reports a successful changeto the application (step 412).

Details of adding an info object received from another session managerto the repository

Finally FIG. 17 depicts the behavior of the session manager when a newor updated info object arrives over the network as the result of achange to an application object 30 by a remote endpoint. Firstly theinfo object resulting from the change arrives (step 500) at the sessionmanager, which first attempts to locate the info object's parentconference object in its repository (step 501). If (step 502) theconference object is not found, the session manager simply discards theinfo object (step 503), as it is not relevant to any endpoints runningon this workstation. However, if a conference object is identified, thenthe info object is incorporated into the repository (step 504) and thesession manager then determines which applications on its workstationare using that conference (step 505). The session manager thencommunicates (step 506) the received info object to each localapplication which is an endpoint of the conference to which the receivedinfo object belongs.

CONCLUSION

The foregoing Detailed Description has disclosed to those skilled in thetechnical areas to which the invention pertains the best mode known tothe inventors of making and using their completely distributed,completely scalable, and completely extensible system for managingconference state. Characteristics of their invention include maintainingidentical copies of a conference's state in the session managers andendpoints in all of the computer systems that have endpoints of theconference, including a distributed locking mechanism in the sessionmanager's conference state and using it to ensure that the copies remainidentical, using a representation of hierarchies in the conference statewhich is valid in any computer system, employing a representation of theendpoint's portion of the conference state in the session managerconference state which is differently from that used in the endpoint,and employing a translator in the endpoint to translate between therepresentation used in the endpoint and the representation used in thesession manager.

Session manager having some or all of the above characteristics may beimplemented in many ways that are different from but equivalent to theways disclosed in the Detailed Description. Since that is the case, theDetailed Description is to be understood as being in all respectsexemplary and not restrictive, and the breadth of the inventiondisclosed herein is to be determined not from the Detailed Description,but rather from the claims as interpreted with the full breadthpermitted by the patent laws.

What is claimed is:
 1. A session manager that executes in a computersystem in which an endpoint of a conference is executing, the conferencebeing made up of endpoints connected by a network, the endpointincluding endpoint conference state for the conference, and the sessionmanager comprising: session manager conference state including adistributed locking mechanism associated with the conference, aninterface to the endpoint, and an interface to the network, the endpointproviding any portion of the endpoint conference state which theendpoint has altered to the session manager via the interface to theendpoint, the session manager responding thereto by sending the alteredportion via the interface to the network to other session managers forthe other endpoints when the locking mechanism associated with theendpoint's conference indicates that the other session managers areready to receive the altered portion, and responding to receipt of analtered portion from another session manager in the network interface byproviding the received altered portion to the endpoint for theconference via the endpoint interface for incorporation into theendpoint's endpoint conference state.
 2. The session manager set forthin claim 1 wherein: the session manager conference state furtherincludes a copy of the endpoint conference state and the session managerincorporates any changes in the endpoint conference state into the copythereof in the session manager conference state.
 3. The session managerset forth in claim 2 wherein: the endpoint conference state has ahierarchy; and the copy of the endpoint conference state in the sessionmanager conference state retains the hierarchy.
 4. The session managerset forth in claim 3 wherein: the session manager conference state has ahierarchy and the copy in the session manager conference state isincluded in that hierarchy.
 5. The session manager set forth in claim 4wherein: the hierarchy in the session manager conference state has arepresentation which remains valid when the session manager conferencestate is sent to a different computer system.
 6. The session manager setforth in claim 4 wherein: the hierarchy is an acyclic directed graph. 7.The session manager set forth in claim 2 wherein: an endpoint may becomean endpoint for a preexisting conference; the endpoint employs theendpoint interface to specify a location of a copy of the preexistingconference's session manager conference state to the session manager;the session manager responds thereto by using the network interface toobtain the copy from the location, incorporating the copy into thesession manager conference state, and providing the endpoint conferencestate in the copy to the endpoint via the endpoint interface.
 8. Thesession manager set forth in claim 2 wherein: an endpoint may establishnew endpoint conference state for a new conference and provide the newendpoint state to the session manager; the session manager responds tothe new endpoint state by making new session manager conference stateand incorporating the new endpoint state therein; and the sessionmanager responds to a request from another session manager for the newsession manager conference state by providing the new session managerconference state to the other session manager via the network interface.9. The session manager set forth in any of claims 2 through 8 wherein:the copy of the endpoint conference state has a representation which isdifferent from the representation thereof in the endpoint; and thesession manager includes a translator which translates any portion ofthe endpoint conference state which the endpoint provides to the sessionmanager from the representation thereof in the endpoint conference stateinto the different representation thereof in the session managerconference state and any portion of the endpoint conference state whichthe session manager provides to the endpoint from the differentrepresentation into the representation thereof in the endpointconference state.
 10. The session manager set forth in claim 9 wherein:the translator executes in the endpoint.
 11. The session manager setforth in claim 10 wherein: the different representation is XML and thetranslator translates between XML and the representation in the endpointconference state according to a DTD that is particular to the endpoint.12. The session manager set forth in claim 9 wherein: the sessionmanager provides any information that is included in the session managerconference state to the network in the representation used in thesession manager conference state.
 13. The session manager set forth inclaim 1 wherein: there are endpoints for a plurality of conferenceexecuting in the computer system, each endpoint having endpointconference state, the session manager further comprises session managerconference state for each of the plurality of conferences, each of thelocking mechanisms therein being associated with a conference of theplurality thereof, and any of the plurality of endpoints that hasaltered its endpoint conference state provides the altered portionthereof via the endpoint interface to the session manager, the sessionmanager responding thereto by sending the altered portion via thenetwork interface to other session managers for the conference to whichthe endpoint that has altered its conference state belongs when thelocking mechanism associated with the conference indicates that theother session managers are ready to receive the altered portion, andresponding to receipt of an altered portion via the network interfacefor any of the plurality of conferences from another session manager byproviding the received altered portion via the endpoint interface to theendpoint for that conference for incorporation into that endpoint'sendpoint state.
 14. The session manager set forth in claim 13 wherein:the session manager comprises session manager conference state only forthose conferences which currently have endpoints executing in thecomputer system.
 15. The session manager set forth in claim 13 wherein:the session manager conference state for each conference furtherincludes a copy of the endpoint conference state for the conference'sendpoint and the session manager incorporates any changes in theendpoint conference state into the copy thereof in the session managerconference state.
 16. The session manager set forth in claim 15 wherein:the endpoint conference state has a hierarchy; and the copy of theendpoint conference state in the session manager conference stateretains the hierarchy.
 17. The session manager set forth in claim 16wherein: a portion of an endpoint's conference state may be shared by aplurality of the conferences; and the session manager alters the copy ofthe shared portion only when the locking mechanism associated with eachof the plurality of conferences indicates that the other sessionmanagers for that conference are ready to receive the altered portion.